copyin_link() tries to allocate (unsigned int)c_filesize + 1 bytes.
If c_filesize == UINT_MAX, this works out as 0 bytes, resulting in a
null pointer and a subsequent SIGSEGV.
The previous commit made this impossible on 32-bit systems.
CVE-2021-31871
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
The maximum name and file sizes in the "new" header format are 32-bit
unsigned values. However, the I/O functions mostly use long for sizes
and offsets, so that sizes >= 2^31 are handled wrongly on 32-bit
systems.
The current GNU cpio code doesn't seem to have this problem, but the
divergence between this version and that is large enough that I can't
simply cherry-pick a fix for it.
As a short-term fix, in read_in_new_ascii(), fail if c_namesize or
c_filesize is > LONG_MAX.
CVE-2021-31872
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
calloc() multiplies its 2 arguments together and passes the result to
malloc(). Since the factors and product both have type size_t, this
can result in an integer overflow and subsequent buffer overflow.
Check for this and fail if it happens.
CVE-2021-31870
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0037-klibc-calloc-Fail-if-multiplication-overflows.patch
malloc() adds some overhead to the requested size, which may result in
an integer overflow and subsequent buffer overflow if it is close to
SIZE_MAX. It should fail if size is large enough for this to happen.
Further, it's not legal for a C object to be larger than
PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could
overflow. So return failure immediately if size is greater than that.
CVE-2021-31873
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
Ben Hutchings [Thu, 19 Jul 2018 20:34:08 +0000 (21:34 +0100)]
resume: Backward compatibility for resume_offset
Forwarded: not-needed
In Debian we will need to maintain backward compatibility with Linux
4.9 at least until after the "buster" release. Therefore we need to
accept that /sys/power/resume_offset might not exist.
If we can't open that file because it doesn't exist, we should check
whether the offset we are trying to set is the offset that the kernel
would use anyway. In that case, continue.
Gbp-Pq: Name resume-backward-compatibility-for-resume_offset.patch
Ben Hutchings [Sat, 5 Jun 2021 18:20:42 +0000 (19:20 +0100)]
klibc (2.0.6-1+deb10u1) buster; urgency=medium
[ Ben Hutchings ]
* Apply security fixes from 2.0.9 (Closes: #989505):
- malloc: Set errno on failure
- malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
- calloc: Fail if multiplication overflows (CVE-2021-31870)
- cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
- cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
[ Thorsten Glaser ]
* {set,long}jmp [s390x]: save/restore the correct FPU registers
(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
projects / klibc.git / log